- 0 minutes to read

Prerequisites for the Nodinite Windows Server Monitoring Agent

Nodinite Windows Server Monitoring Agent delivers robust, secure, and scalable monitoring for your entire Windows Server landscape. This page details all prerequisites to ensure a seamless installation, optimal connectivity, and compliance with best practices.

  • ✅ Secure and scalable monitoring for on-premises and cloud environments
  • ✅ All software, user rights, and firewall requirements in one place
  • ✅ Expert guidance for PowerShell, WinRM, and Service Bus setup
  • ✅ Avoid common pitfalls with clear troubleshooting and FAQ links

This page outlines the prerequisites for installing and running the Nodinite Windows Server Monitoring Agent.

graph LR subgraph "Nodinite Instance" roNI(fal:fa-monitor-waveform Windows Server Monitoring agent) end subgraph "Windows Servers" roWS(fab:fa-windows Windows Server) roNI --- roWS roWS -.-> |Custom PowerShell scripts| roAzureAPI(fab:fa-windows Remote Windows Server) end subgraph "Any pingable device/server" roDevice(fal:fa-router Device) roNI -.- |Ping| roDevice end
*This diagram shows how the agent connects to Windows Servers and pingable devices, supporting both local and remote PowerShell scripts.*

You can install this agent on-premises using TCP/IP for local network access, or in the cloud/off-site using Service Bus Relaying. For more details, see the external link 'Azure Relay FAQs'.

We recommend keeping this agent close to Nodinite Core Services. This documentation covers local network setup (usually on the Nodinite application server)

Verified Topic
Software Requirements
What Windows User Rights does the Windows Server Monitoring agent require?
What Firewall settings do the Nodinite Windows Server Monitoring agent require?
WinRM must be enabled for remote PowerShell. Some IIS Monitoring features rely on remote PowerShell

Software Requirements

The Windows Server Monitoring Agent is a Windows Service and is usually installed on the Nodinite application server.

Product
Windows Server Windows 2025
Windows 2022
Windows 2019
Windows 2016
Windows 2012 R2*
Windows 2012*
.NET Framework .NET Framework 4.8 or later New 6.0
Our recommendation is .NET Framework 4.8.1 or later
Powershell WMF 5.1 or later If you are using Windows 2012/2012 R2, you must install WMF 5.1 or later to make use of the PowerShell Monitoring feature. Also, some IIS Monitoring features rely on PowerShell.
IIS Monitoring (Agent Host) * Remote Powershell must be enabled for some IIS Monitoring features, follow the WinRM instructions*
IIS Monitoring (Target Host) * IIS Management Console
* IIS 6 Metabase Compatibility
* IIS 6 Management Compatibility
* IIS 6 WMI Compatibility
* Management Service (Please review the additional heading)
* Troubleshooting IIS Monitoring on Windows Server 2012 R2 and earlier
* Target server must have Web Scripting Tools installed. Use the following PowerShell command to install the feature: 'Install-WindowsFeature Web-Scripting-Tools'
* Remote Powershell must be enabled for some IIS Monitoring features, follow the WinRM instructions*

Versions 6.2 and later do no longer require the Microsoft.Web.Administration assembly on Agent Host.
Versions 6.0 and later make use of the .NET Framework 4.8 or later.
Versions 5.4 and later make use of the .NET Framework 4.6.2 or later.
Versions prior to 5.4 make use of the .NET Framework 4.5.2 or later.

Remote Windows Servers with IIS to monitor must have these Windows features installed.
IIS 6 Features
IIS 6 roles and features required for remote monitoring.

If you have three servers with IIS to monitor, you must install this feature on three servers
If you see entries in the Event Log like while activating CLSID {2B72133B-3F5B-4602-8952-803546CE3344}, please review the prereqs, restart, and make sure the following settings have been applied: Setting DCOM Security to Allow a User to Access a Computer Remotely

Management Service

If the IIS is a remote server to the Monitoring Agent; You must also enable remote connections and make sure the WMSVC service is operational. Please review the Remote Administration for IIS Manager for additional details.

  1. Enable remote connections
  2. Make sure to auto-start the VMSVC service
    Management Service
    Ensure to allow remote connections and set the 'WMSVC' service to start automatically.

Enable remote connections

  1. In the IIS MMC, click on the node, then, on Management Service.
  2. Check the Enable remote connections checkbox.

Click the Apply to persist the changes.

Apply changes
Click Apply to persist the changes.

Set WMSVC to start automatically

The WMSVC service installs with Startup Type set to Manual, which means that the service has to be manually restarted each time the server reboots or if HTTP.sys is stopped (WMSVC depends on HTTP.sys). Set the Startup Type to Automatic if you want WMSVC to start on system boot. Do this in the Services MMC console, or using this command line in an administrative command prompt:

sc.exe config WMSVC start= auto

Supported Versions

Windows Server is ever-evolving, and Microsoft sometimes adds new functionality and/or deprecates older SDKs, methods and adjust policies. For Nodinite, this means you need to update Nodinite and our Windows Server Monitoring Agent from time to time.

Make sure to subscribe to our Release Notes.

What Windows User Rights does the Windows Server Monitoring agent require?

You will install the monitoring agent as a Windows Service, usually on the Nodinite application server. Virtual machines are supported.

To be operational, the Service Account running the Nodinite Windows Server Monitoring Agent must be the local administrator on all servers to monitor.

What Firewall settings do the Nodinite Windows Server Monitoring agent require?

Depending on where on the network you install the Windows Server Monitoring Agent and the Nodinite Monitoring Service; To monitor Windows Servers, you may need different firewall configurations on other servers. The following illustration shows the agent installed on a dedicated Windows Server.

graph TD subgraph "Nodinite Instance" roMonitoringService(fal:fa-watch-fitness Monitoring Service) roNI(fal:fa-monitor-waveform Windows Server Monitoring agent) roMonitoringService --> |"TCP/HTTPS"| roNI roWS1(fab:fa-windows Local Windows Server) end subgraph "Other Windows Servers" roAzureAPI(fab:fa-windows Remote Windows Server) roNI -.-> |WMI, RPC, ...| roAzureAPI roNI --> roWS1 end
*This diagram illustrates agent and service communication, including remote WMI and RPC traffic.*

The Windows Server Monitoring Agent has both inbound and outbound communication:

  1. Between the Monitoring Service and the Windows Server Monitoring Agent
  2. Between the Windows Server Monitoring Agent and monitored Windows Server(s)
    • Local (no ports required)
    • Remote ports are used

1. Between the Monitoring Service and the Windows Server Monitoring agent

The following ports must be allowed on the Windows server where the agent is installed and running:

Port Name Inbound Outbound TCP UDP Comment
53 DNS ✅ ✅ ✅ The Agent needs to know where your other servers/services are (can sometimes optionally be solved using entries in the local hosts file)

And further with 'Option 1' or 'Option 2' as documented next:

Option 1 (Local network)

Port Name Inbound Outbound TCP UDP Comment
8000 RPC ✅ ✅ Communication is initiated by the Monitoring Service

Option 2 (Cloud/Hybrid)

Use Service Bus Relayed connections when Nodinite and the agent are on totally different networks.

Nodinite uses the same principle technique as the On-Premise data gateway; see 'Adjust communication settings for the on-premises data gateway' user guide.

Port Name Inbound Outbound TCP UDP Comment
443 HTTPS ✅ ✅ Secure outbound traffic
5671, 5672 Secure AMQP ✅ ✅
9350 - 9354 Net.TCP ✅ ✅

2. Between the Windows Server Monitoring agent and Windows Servers

There is RPC and WMI traffic between the Windows Server Monitoring Agent and the monitored Windows Servers (1..*)

graph TD subgraph "Nodinite Instance" roNI(fal:fa-monitor-waveform Windows Server Monitoring agent) roWS1(fab:fa-windows Local Windows Server) end subgraph "Other Windows Servers" roNI -.-> |135, 445, ...| roAzureAPI(fab:fa-windows Remote Windows Server) roNI --> roWS1 end
*This diagram shows agent-to-server communication for RPC and WMI monitoring.*

On any Windows Server where the agent is installed, the following ports must be open for the Windows Server Monitoring Agent to connect and monitor the server and possibly other remote Windows Servers:

Port Name Inbound Outbound TCP UDP Comment
ICMP PING ✅ ICMP. Note As per your user configuration; apply to the device/servers to ping
53 DNS ✅ ✅ ✅ The Agent needs to know where your other servers/services are (can sometimes optionally be solved with user-defined entries in the hosts file in each Windows server instance), review the following 'Microsoft' user guide
88 Kerberos ✅ (only on DC Servers) ✅ ✅ ✅ Review 'Microsoft Kerberos' user guide
135 RPC ✅ ✅ This port is shared between many Windows Services
445 SMB, RPC/NP ✅ ✅ Windows Performance Counters Access
49152–49162 RPC dynamic ports WMI/RPC ✅ ✅ For all monitoring features, you can safely reduce the dynamic RPC port range to as few as 10 ports (e.g., 49152–49162) based on your expected concurrency. See How to configure RPC dynamic port allocation to work with firewalls

On any remote Windows Server to monitor (thus, the Agent is NOT installed on this remote server), the following ports must be open for the Nodinite Windows Server Monitoring Agent to connect and monitor the server:

Port Name Inbound Outbound TCP UDP Comment
ICMP Ping ✅ Outbound ICMP for availability checks
53 DNS ✅ ✅ ✅ Outbound DNS for name resolution
88 Kerberos ✅ ✅ ✅ Outbound Kerberos for authentication
135 RPC ✅ ✅ Inbound RPC for remote management
445 SMB, RPC/NP ✅ ✅ Inbound SMB/RPC for performance counters
49152–49162 RPC dynamic ports WMI/RPC ✅ ✅ Inbound RPC dynamic ports for WMI/RPC. You can safely reduce the dynamic RPC port range to as few as 10 ports (e.g., 49152–49162) based on your expected concurrency.

Add firewall rule

If you want to monitor the IIS on a remote Windows server, additional firewall exclusions may be required.

Please add a new firewall rule on the remote server to monitor to allow the dllhost.exe to accept incoming requests from the Nodinite Windows Server Monitoring Agent.

Setting Value
Rule type Inbound
Rule type Custom
Program %systemroot%\system32\dllhost.exe
Protocol TCP
Local port RPC Dynamic Ports
Remote port All Ports
Action Allow connection
Profile Domain 
netsh advfirewall firewall add rule name="Remote IIS inetinfo" dir=in action=allow description="Remote IIS Service Managment" program="%systemroot%\System32\inetsrv\inetinfo.exe" enable=yes  

netsh advfirewall firewall add rule name="COM+ Remote Administration (All Programs)" dir=in action=allow description="" program="%windir%\system32\dllhost.exe" enable=yes localport=RPC protocol=tcp

WinRM

⚠️WinRM must be enabled on remote Windows Server if you are using the PowerShell feature with remote target.

Run the scripts below on the remote server to enable WinRM:

The user must have administrator rights on the remote server.

Enable-PSRemoting -Force

Firewall rules must allow PowerShell Remoting (TCP 5985 for HTTP, TCP 5986 for HTTPS).

New-NetFirewallRule -Name "Allow WinRM" -DisplayName "Allow WinRM" -Enabled True -Profile Any -Direction Inbound -Action Allow -Protocol TCP -LocalPort 5985

Frequently asked questions

Additional solutions to common problems and the FAQ for the Nodinite Windows Server Monitoring Agent exist in the Troubleshooting user guide.

Next Step

Install Windows Server Monitoring Agent

Add or manage a Monitoring Agent Configuration
Monitoring
Administration